DOORS 9.1 upgrade/auto declare string error

SystemAdmin - Fri Mar 13 08:05:16 EDT 2009
9.1 does not have auto-declare off by default (it should be, as Tony has replied), but it seems that something has changed. In 8.3 while allowing auto-declare you could write code like:

o = current Object
i = identifier o
print i

This does not anymore work in DOORS 9.1 - it complains about line 2, as you noted.
Did not find anything about this in 9.1 DXL Help...

Tony_Goodman - Fri Mar 13 09:43:53 EDT 2009
I think I know what is happening now.

It does not complain about
o = current Object
because this is unambiguous, o must be of type Object, and proves that autodeclare is ON.

But it does complain about
i = identifier o
which leads me to believe that in 9.1 identifier() has been overloaded to return a different type. I can't prove this because I don't have 9.1 in front of me.

Did you find any other examples?

the@dmin - Fri Mar 13 13:05:25 EDT 2009
Thanks everybody.

Tony, the only instance I find that this is an issue with is the identifier. I get errors on almost every module, so the sooner I get this fixed, the better. So far, I have fixed just the identifier and the errors go away as I fix them...but to correct in at least 100 modules will be quite a task!

Corey

kbmurphy - Fri Mar 13 15:43:47 EDT 2009
I don't like autodeclare myself...but another way to fix this is to change the line:

i = identifier o

to:

i = identifier o ""

I have gotten into the habit of always ending with "" whenever I'm doing anything with a string.

Also, if you have hundreds of modules that you have to update, you're doing something wrong. Use #includes.

llandale - Tue Mar 17 12:38:10 EDT 2009
Goodman is right as usual:

<1> AutoDeclare is a disaster; much like designing a pistol that conveniently turns off the safety whenever you pick it up. Insert "XFLAGS_ &=~AutoDeclare_ " line of DXL in file <C:\Program Files\Telelogic\DOORS_?.?\lib\dxl\startup.dxl> and search the forums for script 'AutoDeclareSet.dxl' which lets you turn it on and off at will, such as when you open a module when some other bozo wrote some attrDXL with AutoDeclare on.

<2> Always declare your variables. Seeesh. If for no other reason it lets the next bozo reading your code a year from now tell what's going on better.

<3> If it only complains about 'identifier' auto declared variables, then the new DOORS has added a new 'identifier' perm that takes 'Object' as the parameter; this new perm returns a type other than 'string' and it now has precedence over the other overloaded 'identifier' function that does indeed return a string. Someone with DOORS 9 installed can check that out, either looking closely in the Help file or taking the nerd approach and editing the doors.exe. file looking for 'identifier'.

<4> I suppose its remotely possible that the 'identifier' perm is now confused over a lack of parenthesis around 'othero', but I doubt it. Check that out by trying "i = identifier(othero)".

<5> But WAIT!!! Perhaps you have some sort of "othero = target(link)" further up in the code, and 'othero' is not actually defined as Object (as in v8.1) but rather implicitly as perhaps ModName_ (as in 9.0).

• Louie

Doug.Zawacki - Wed Mar 18 12:28:41 EDT 2009
Folks,

Just thought I should mention that autodeclare is machine dependent. Meaning that you can turn it off on one machine but it can still be turned on in another machine. That's because you add that into the startup.dxl. Therefore, make sure the autodeclare is set on all machines you work in DOORS.

the@dmin - Thu Mar 19 13:11:33 EDT 2009
Thanks everybody, sorry I haven't replied, I've been out of the office.

DOORS 9.1 calls out the identifier in the Analysis Wizard as follows:

s = (identifier othero)

I put in a PMR with IBM and the said the same thing as kbmurphy, which is basically the same as calling it out as a string.

Does anybody remember how the Analysis Wizard in previous versions called out the identifier?

My biggest issue is that I have to somehow get the fix, whatever it may be, and have it updated in about 100 or more modules, with multiple instances in each module. I do not have the time to do that!

Thanks,
Corey

the@dmin - Thu Mar 19 13:11:33 EDT 2009
Thanks everybody, sorry I haven't replied, I've been out of the office.

DOORS 9.1 calls out the identifier in the Analysis Wizard as follows:

s = (identifier othero)

I put in a PMR with IBM and the said the same thing as kbmurphy, which is basically the same as calling it out as a string.

Does anybody remember how the Analysis Wizard in previous versions called out the identifier?

My biggest issue is that I have to somehow get the fix, whatever it may be, and have it updated in about 100 or more modules, with multiple instances in each module. I do not have the time to do that!

Thanks,
Corey

the@dmin - Thu Mar 19 13:11:33 EDT 2009
Thanks everybody, sorry I haven't replied, I've been out of the office.

DOORS 9.1 calls out the identifier in the Analysis Wizard as follows:

s = (identifier othero)

I put in a PMR with IBM and the said the same thing as kbmurphy, which is basically the same as calling it out as a string.

Does anybody remember how the Analysis Wizard in previous versions called out the identifier?

My biggest issue is that I have to somehow get the fix, whatever it may be, and have it updated in about 100 or more modules, with multiple instances in each module. I do not have the time to do that!

Thanks,
Corey

Tony_Goodman - Fri Mar 20 05:16:15 EDT 2009
Another option. Add the following line to startup.dxl:
string s = ""

This should just be a temporary measure to stop the dxl errors so you can open the modules and fix the layout DXL properly.

As Kevin suggests, you will need to fix the layout DXL, but I suggest you fix it by adding the above line (i.e. declaring the variable) rather than adding an empty string to the identifier call. This way it will also work with autodeclare turned off.

kbmurphy - Thu Mar 19 16:33:04 EDT 2009
Corey,

I believe IBM made some changes to the Analysis Wizard code.

I can't prove this outright right now, but I believe it used to be that if Attribute Names were included in Analysis Wizard output they were bolded. In DOORS 9.1, they aren't bolded, and there is no option to bold them, though you can go in and do it manually.

Even if I'm wrong about this, I would definitely call this a bug...standard code generated by previous versions of DOORS now does not work.

It sounds like you upgraded to DOORS 9.1 without testing out this stuff. You should always run some tests with a clone of production data before even doing a minor upgrade. I know you shouldn't have to, but you can't just Telelogic/IBM to not break things.

So how to fix this? The way I see it you have a few options:

1. Verse yourself in DXL. For each module in the database, open it, and for each view, determine whether each column is layout, and if it's layout, search the DXL for "identifier (o)" and change it to "identifier (o)" "" The logic is simple, but the mechanics won't be.

2. Complain LOUDLY to IBM and have them write the script to accomplish suggestion 1. They broke their code.

3. Send an email to all of your users about the problem and tell them how to fix it themselves, reminding them to save their views when they are done.

the@dmin - Tue Mar 24 15:53:11 EDT 2009
I did put in a PMR with IBM to address the issue. They gave me some code that I can run to correct the issue in layout DXL. However, I would have to define each module and run from each module (attached). I might try and modify it to run through the database on its own...plus they set the script up to open the module for viewing, but I don't know if that is necessary or not.

I also need to try and tackle writing a similar script for attribute DXL. We do have some attribute DXL that was converted from Layout DXL with the same issue.

the@dmin - Tue Mar 24 16:21:51 EDT 2009
Oh, and opening the module for viewing is necessary, otherwise the views don't load and errors are reported.

kbmurphy - Tue Mar 24 19:24:14 EDT 2009
I looked at the code and unless I'm mistaken, I highly doubt this code will work for you.

First, the very first line in the code is not the best way to do this. You don't have to be in Exclusive Edit mode to update a view that uses layout DXL.

Secondly, there is no use of regular expressions. This means that unless your layout DXL is:

i = identifier (current Object)

--nothing more and nothing less, this code will not work.

Third, when the view is saved, access rights are not checked. This script assumes that you have M access to every view (and if you're the Administrator you do).

Further, no output of which views were updated are created--so you don't have a way of knowing what the code actually did.

Someone just hacked this code together in about 5 to 10 minutes. They even left a print statement in that does nothing but confuse....

Test this code first. If it does what you want, great. But unfortunately I think you have some work to do.

And BTW, if you update attribute DXL, you must be in Exclusive Edit mode.

Tony_Goodman - Wed Mar 25 05:00:01 EDT 2009
I hadn't looked at the code until I saw Kevin's post, then I got curious.

Did IBM supply this code?
If so then I think you should ask them to try again.

As Kevin has pointed out, the script is useless.

kbmurphy - Wed Mar 25 12:56:38 EDT 2009
Wow! For once, I was actually nicer than someone else when it came to describing Telelogic/IBM's competence.

I agree with Tony--the code is completely useless, but for once, I'm not the one that said it. It feels...refreshing. :)

Doug.Zawacki - Wed Mar 18 12:28:41 EDT 2009
Folks,

Just thought I should mention that autodeclare is machine dependent. Meaning that you can turn it off on one machine but it can still be turned on in another machine. That's because you add that into the startup.dxl. Therefore, make sure the autodeclare is set on all machines you work in DOORS.

the@dmin - Thu Mar 26 09:53:37 EDT 2009
After much testing and manipulating, I have not been able to get the script to actually change anything. It will run through the defined module, open and close views, and actually print the layout DXL with modifications...but in the end, nothing is changed. I will send this back to IBM for round 2! Stay tuned....

kbmurphy - Thu Mar 26 12:38:47 EDT 2009
Hey @admin,

I told you so. Tony told you so. The script is useless junk. I can't believe they actually sent that to you.

When you contact them again, ask them to spend more then 10 minutes coding a solution to a problem they caused.

In another thread about TPE, I accused IBM/Telelogic of not understanding how their customers use DOORS. Ben Williams disagreed. It's things like this that continue to show me I'm right in that statement. The person who wrote this code did not understand the problem and thus did not listen to the customer to begin with.

This is what your maintenance/support fees pay for....

Kevin

the@dmin - Thu Mar 26 13:15:30 EDT 2009
Louie,

Unfortunately for me, I inherited bad programming habits from learning how to do coding on my own, using the existing coding folks already wrote. I did not find out about AutoDeclare until I took the DXL programming class not too long ago (which was actually very informative for me). But, but then, all the damage done in the past by me and others was already done.

Kevin,

I told Telelogic that the script was useless...they wrote back and asked me to explain. I basically rewrote my first email as to why the code does not work. I will wait to hear what they have to say. Now that I see what they are doing, I am almost tempted to write code myself to fix it...

Thanks,
Corey

the@dmin - Thu Mar 26 13:15:30 EDT 2009
Louie,

Unfortunately for me, I inherited bad programming habits from learning how to do coding on my own, using the existing coding folks already wrote. I did not find out about AutoDeclare until I took the DXL programming class not too long ago (which was actually very informative for me). But, but then, all the damage done in the past by me and others was already done.

Kevin,

I told Telelogic that the script was useless...they wrote back and asked me to explain. I basically rewrote my first email as to why the code does not work. I will wait to hear what they have to say. Now that I see what they are doing, I am almost tempted to write code myself to fix it...

Thanks,
Corey

Tony_Goodman - Fri Mar 27 07:24:19 EDT 2009
Trying to fix broken Layout DXL automatically would be almost impossible unless you know the exact string(s) to replace. I suggest simply removing the bad layout dxl all together.

I knocked together the attached script to help you. It will scan all the modules below the current folder and report any columns found that cause dxl errors. If you check the toggle box then it will remove the dxl for you.

I suggest you try it on a test area first as I only tested it quickly.
You will need to run it as administrator if you want to fix public (read-only) views.

It will of course take some time to run if there are lots of modules.

Best of luck.

the@dmin - Fri Mar 27 09:09:07 EDT 2009
Thanks everybody...IBM sent another DXL code that is supposed to work. I ran it and came up with the same results...no dice! My budget allocations for DOORS is very slim right now, so I will have to see if my management will allow me to spend some time writing the code.

Attached is the updated code for those interested.

Tony_Goodman - Fri Mar 27 09:33:23 EDT 2009

That new code should work, even if it is a bit brutal.

However, it is still not correct.

change

while (hasString layoutCode)
                        {
                                        layoutCode = "string i\n" layoutCode
                                        dxl (c, layoutCode)
                                        save v
                                        layoutCode = layoutCode[end 0+2:]
                                }

to

if(hasString layoutCode)
                        {
                                        layoutCode = "string i\n" layoutCode
                                        dxl (c, layoutCode)
                                        save v
                                }

David_G_Bond - Tue Mar 31 17:24:16 EDT 2009
A note of caution. One script I developed in which a variable was not declared did not produce an error message but produced incorrect data. It took a long time to finde the problem.

Since then I have had auto-declare turned off on my machine. Period.

David Bond
The Boeing Company

Tony_Goodman - Fri Mar 27 09:33:23 EDT 2009

That new code should work, even if it is a bit brutal.

However, it is still not correct.

change

while (hasString layoutCode)
                        {
                                        layoutCode = "string i\n" layoutCode
                                        dxl (c, layoutCode)
                                        save v
                                        layoutCode = layoutCode[end 0+2:]
                                }

to

if(hasString layoutCode)
                        {
                                        layoutCode = "string i\n" layoutCode
                                        dxl (c, layoutCode)
                                        save v
                                }